Method and apparatus for analyzing and mitigating noise in a digital subscriber line

ABSTRACT

Data indicative of a level of stability of a DSL link is received. Based on the received data, it is determined whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold. If the level of stability of the DSL link is below the minimum threshold, die noise associated with the DSL link before the time of failure is compared with the noise associated with the DSL link after the time of failure. If the difference between the noise before and after the time of failure exceeds a threshold, then the difference in noise is characterized as a stationary noise associated with the DSL link. However, if the difference between the noise before and after the time of failure is below the threshold, a determination is made whether the failure is associated with a loss of power to the DSL link or a severe impulse noise event—the difference in noise is characterized accordingly. Finally, the characterization of the noise associated with the DSL link is preserved for subsequent possible reconfiguration of the DSL link to improve link stability.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of and claims priority to U.S.application Ser. No. 12/375,216, filed Aug. 24, 2009, which is a 371 ofPCT/US07/17077, filed Jul. 31, 2007, which claims the benefit of U.S.Provisional Patent Application No. 60/834,436. entitled DSL System,filed Jul. 31, 2006. This application is related to U.S. patentapplication Ser. No. 10/795,593, entitled Adaptive Codeword Management,filed 8 Mar. 2004. This application is related to U.S. patentapplication Ser. No. 10/817,128, entitled DSL System Estimation andParameter Recommendation, filed 2 Apr. 2004. This application is relatedto Patent Cooperation Treaty (PCT) Application No. US2006/026796,entitled Adaptive Margin and Band Control, filed 8 Jul. 2006.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to a method and apparatus for analyzingand improving the quality and stability of digital communicationsystems. More specifically, this invention relates to analyzing andmitigating link failures and errors in a DSL system.

2. Description of Related Art

Digital subscriber line (DSL) technologies provide potentially largebandwidth for digital communication over existing telephone subscriberlines (referred to as loops and/or the copper plant). Telephonesubscriber lines can provide this bandwidth despite their originaldesign for only voice-band analog communication. In particular,asymmetric DSL (ADSL) and very-high-speed DSL (VDSL) can adjust: to thecharacteristics of the subscriber line by using a discrete multitone(DMT) line code that assigns a number of bits to each tone (orsub-carrier), which can be adjusted to channel conditions as determinedduring training and initialization of the modems (typically transceiversthat function as both transmitters and receivers) at each of thesubscriber line. DSL systems can use vectoring technologies, where jointtransmitter and/or joint receiver signal processing can be performedamong multiple pairs to mitigate the effects of crosstalk interference,and thus to improve performance.

DSL systems would further benefit from determining the cause of DSL linkinstability and/or poor link quality that can lead to DSL link failureor link errors, and taking measures to improve link stability and/orlink quality.

SUMMARY

An embodiment of the invention comprises a means and method to collectdata, perform analysis of the data to characterize causes leading to DSLlink failures and or DSL link errors, and once the causes aredetermined, reconfiguring the DSL link to mitigate the failures and/orerrors.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and notby way of limitation in the figures of the accompanying drawings inwhich like references indicate similar elements. It should be noted thatreferences to “an” or “one” embodiment in this disclosure are notnecessarily to the same embodiment, and such references mean “at leastone.”

FIG. 1 shows the reference model diagram for a DSL system from the ITU-TG.977.1 standard.

FIG. 2 illustrates a general schematic diagram of a DSL system, showingthe layout and operation of the system.

FIG. 3A illustrates a DSL optimizer coupled in communication with a DSLsystem in accordance with an embodiment of the invention.

FIG. 3B illustrates a DSL optimizer that operates in connection with aDSLAM in accordance with an embodiment of the invention.

FIG. 4 illustrates a flow diagram in accordance with one embodiment ofthe invention.

FIG. 5 illustrates a characterization of impulse noise over a timeperiod.

FIG. 6 illustrates a flow diagram in accordance with one embodiment ofthe invention.

FIG. 7 illustrates the locations of bytes within a RS codeword that havehigh probability of being corrupted by impulse noise, in accordance withan embodiment of the invention.

FIG. 8 illustrates a computer system for use by a user and/or controllerin accordance with one or more embodiments of the invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows the reference model system according to the G.997.1standard (G.ploam). This model applies to all ADSL systems meeting thevarious standards that may or may not include splitters, such as ADSL1(G.992.1), ADSL-Lite (G.992.2), ADSL2 (G.992.3), ADSL2-Lite G.992.4,ADSL2+ (G.992.5) and the G.993.1 and G.9932 VDSL standards, as well asthe G.991.1 and G.991.2 SHDSL standards, all with and without bonding.This model is well known to those skilled in the art.

The G.997.1 standard specifies the physical layer management for ADSLtransmission systems based on the clear embedded operation channel (EOC)defined in G.997.1 and use of indicator bits and EOC messages defined inG.992.x and G.993.x standards. Moreover, G.997.1 specifies networkmanagement elements content for configuration, fault and performancemanagement. In performing these functions, the system utilizes a varietyof operational data that is available at an access node (AN).

In FIG. 1, users' terminal equipment 110 is coupled to a home network112, which in turn is coupled to a network termination unit (NT) 120. NT120 includes an xTU-R 122 (for example, a transceiver defined by one ofthe ADSL standards) or any other suitable network termination modem,transceiver or other communication unit. NT 120 also includes amanagement entity (ME) 124. ME 124 can be any suitable hardware device,such as a microprocessor, microcontroller, or circuit state machine infirmware or hardware, capable of performing according to any applicablestandards and/or other criteria. ME 124 collects and stores performancedata in its Management Information Base (MIB), which is a database ofinformation maintained by each ME. The MIB can be accessed via networkmanagement protocols such as SNMP (Simple Network Management Protocol),an administration protocol used to gather information from a networkdevice to provide to an administrator console/program, or via TL1commands, TL1 being a well known command language used to programresponses and commands between telecommunication network elements.

Each xTU-R in a system is coupled to an xTU-C in a Central Office (CO)or other central location. In FIG. 1, xTU-C 142 is located at an accessnode (AN) 140 in a CO 146. An ME 144 likewise maintains an MIB ofperformance data pertaining to xTU-C 142. The AN 140 may be coupled to abroadband network 170 or other network, as will be appreciated by thoseskilled in the art. xTU-R 122 and xTU-C 142 are coupled together by aloop 130, which in the case of ADSL and VDSL typically is a telephonetwisted pair that also carries other communication services.

Several of the interfaces shown in FIG. 1 are used for determining andcollecting performance data. The Q-interface 155 provides the interfacebetween the Network Management Station (NMS) 150 of the operator and ME144 in AN 140. All of the parameters specified in the G.997.1 standardapply at the Q-interface 155. The near-end parameters supported in theME 144 are derived from xTU-C 142, while the far-end parameters fromxTU-R 122 can be derived by either of two interfaces over theU-interface. Indicator bits and EOC messages, which are sent usingembedded channel 132 and are provided at the PMD layer, can be used togenerate the xTU-R 122 parameters in ME 144. Alternately, the OperationAdministration and Management (OAM) channel and a suitable protocol canbe used to retrieve the parameters from xTU-R 122 when requested by ME144. Similarly, the far-end parameters from xTU-C 142 can be derived byeither of two interfaces over the U-interface. Indicator bits and EOCmessages, which are provided at the PMD layer, can be used to generatethe xTU-C 142 parameters in ME 122 of NT 120. Alternately, the OAMchannel and a suitable protocol can be used to retrieve the parametersfrom xTU-C 142 when requested by ME 124.

At the U-interface (which is essentially loop 130), there are twomanagement interfaces, one at xTU-C 142 (the U-C interface 157) and oneat xTU-R 122 (the U-R interface 158). Interface 157 provides xTU-Cnear-end parameters for xTU-R 122 to retrieve over the U-interface 130.Similarly, interface 158 provides xTU-R near-end parameters for xTU-C142 to retrieve over the U-interface 130. The parameters that apply maybe dependent upon the transceiver standard being used (for example,G.992.1 or G.922.2).

The G.997.1 standard specifies an optional OAM communication channelacross the U-interface. If this channel is implemented, xTU-C and xTU-Rpairs may use it for transporting physical layer OAM messages. Thus, thetransceivers 122, 142 of such a system share various operational andperformance data maintained in their respective MIBs.

More information can be found regarding ADSL NMSs in DSL Forum TechnicalReport TR-005, entitled “ADSL Network Element Management” from the ADSLForum, dated March 1998, which is well known to those skilled in theart. Also, as noted above, DSL Forum Technical Report TR-069, entitled“CPE WAN Management Protocol” dated May 2004 is well known to thoseskilled in the art. Finally, DSL Forum Technical Report TR-064, entitled“LAN-Side DSL CPE Configuration Specification” dated May 2004 is wellknown to those skilled in the art. These documents address differentsituations for CPE side management. More information about VDSL can befound in the ITU standard G.993.1 (sometimes called “VDSL1”) and the ITUstandard G.993.2 (sometimes called “VDSL2”), as well as several DSLForum working texts in progress, all of which are known to those skilledin the art. Additional information is available in the DSL Forum'sTechnical Report TR-057 (Formerly WT-068v5), entitled “VDSL NetworkElement Management” (February 2003) and Technical Report TR-065,entitled “FS-VDSL EMS to NMS Interface Functional Requirements” (March2004) and Technical Report TR-106 entitled “Data Model Template forTR-069 Enabled Devices,” as well as in the revisions of ITU standardG.997.1 for VDSL2 MIB elements, or in the ATIS Dynamic SpectrumManagement Report, ATIS-0600007. Further information may be found in DSLForum draft working texts WT-105 entitled “Testing & Interoperability:ADSL2/ADSL2plus Functionality Test Plan” and WT-115 entitled “Testing &Interoperability: VDSL2 Functionality Test Plan” and WT-121 entitled“DSL Home Technical: TR-069 Implementation Guidelines.

As will be appreciated by those skilled in the art, at least some of theparameters described in these documents can be used in connection withembodiments of the invention. Moreover, at least some of the systemdescriptions are likewise applicable to embodiments of the invention.Various types of operational data and information available from a DSLNMS can be found therein; others may be known to those skilled in theart.

In a typical topology of a DSL plant, in which a number of transceiverpairs are operating and/or available, part of each subscriber loop iscollocated with the loops of others users within a multi-pair binder (orbundle). After the pedestal, very close to the Customer PremisesEquipment (CPE), the loop takes the form of a drop wire and exits thebundle. Therefore, the subscriber loop traverses two differentenvironments. Part of the loop may be located inside a binder, where theloop is sometimes shielded from external electromagnetic interference,but is subject to crosstalk dues to its proximity to other loops in thebinder. After the pedestal, the drop wire is often unaffected bycrosstalk due to its being farther away from other pairs for most of thedrop, but transmission can also be more significantly impaired byelectromagnetic interference because the drop wires are unshielded. Manydrop wires have 2 to 8 twisted-pairs within them and in situations ofmultiple services to a home or bonding (multiplexing and demultiplexingof a single service) of those lines, additional substantial crosstalkcan occur between these lines in the drop segment.

A generic, exemplary DSL deployment scenario is shown in FIG. 2. All thesubscriber loops of a total of (L+M) users 291, 292 pass through atleast one common binder 240. Each user is connected to a Central Office210, 220 through a dedicated line. However, each subscriber loop may bepassing through different environments and mediums. In FIG. 2, L users291 are connected to CO 210 using a combination of optical fiber 213 andtwisted copper pairs 217, which is commonly referred to as Fiber to theCabinet (FTTCab) or Fiber to the Curb. Signals from transceivers 211 inCO 210 have their signals converted by optical line terminal 212 andoptical network terminal 215 in CO 210 and optical network unit (ONU)218. Modems 216 in ONU 218 act as transceivers for signals between theONU 218 and users 291.

The loops 227 of the remaining M users 292 are copper twisted pairsonly, a scenario referred to as Fiber to the Exchange (FTTEx). Wheneverpossible and economically feasible, FTTCab is preferable to FTTEx, sincethis reduces the length of the copper part of the subscriber loop, andconsequently increases the achievable rates. The existence of FTTCabloops can create problems to FTTEx loops. Moreover, FTTCab is expectedto become an increasingly popular topology in the future. This type oftopology can lead to substantial crosstalk interference and may meanthat the lines of the various users have different data carrying andperformance capabilities due to the specific environment in which theyoperate. The topology can be such that fiber-fed “cabinet” lines andexchange lines can be mixed in the same binder.

As can be seen in FIG. 2, the lines from CO 220 to users 292 sharebinder 222, which is not used by the lines between CO 210 and users 291.Moreover, another binder 240 is common to all of the lines to/from CO210 and CO 220 and their respective users 291, 292.

According to one embodiment of the invention shown in FIG. 3A, ananalyzer 300 may be part of an independent entity monitoring one or moreDSL systems as a controller 310 (for example, a DSL optimizer, a dynamicspectrum manager or dynamic spectrum management center) assisting usersand/or one or more system operators or providers in optimizing orotherwise controlling their use of the system. (A dynamic spectrummanager may also be referred to as a Dynamic Spectrum Management Center,DSM Center, DSL Optimizer, Spectrum Maintenance Center or SMC.) In someembodiments, the controller 310 may be operated by an Incumbent LocalExchange Carrier (ILEC) or Competitive Local Exchange Carrier (CLEC)operating DSL lines from a CO or other location. In other embodiments, a“smart” modem unit can have a controller (having, for example, aprocessor and memory) integrated with the modem in a user location, acentral office or some other single location. As seen from the dashedline 346 in FIG. 3A, controller 310 may be in or part of the CO 146 ormay be external and independent of CO 146 and any party operating withinthe system. Moreover, controller 310 may be connected to and/orcontrolling multiple COs. Likewise, components of controller 310 may ormay not be in the same location and/or equipment, and/or may instead beaccessed by the controller at different locations.

In the exemplary system of FIG. 3A, the analyzer 300 includes collectingmeans 320 (which also may perform monitoring, if desired) and analyzingmeans 340. As seen in FIG. 3A, the collecting and/or monitoring means320 may be coupled to and may collect data through and from sourcesinternal to a DSL system, such as NMS 150, ME 144 at AN 140 and/or theMIB 148 maintained by ME 144. Data also may be collected from externalsources by means 320 through the broadband network 170 (for example, viathe TCP/IP protocol or other means outside the normal internal datacommunication systems within a given DSL system). Also, the collectingmeans 320 may have access to one or more databases or other sources 348,storing binder-level information, such as deployment information,topology information, crosstalk coupling, etc, or information aboutmodem capabilities, such as procedures for bit loading and powerallocation, and service priorities. The controller may collectoperational data from an xTU-R over the Internet or even from an xTU-Cover the Internet if the EMS bandwidth is limited or if the EMS isuncooperative (for example, by blocking reported management data becausethe equipment manufacturer wishes to perform the management internallyto its equipment). Operational data also can be collected from the NMSof the service providers, which may be collecting from various sourcesitself.

Analyzing means 340 and/or monitoring/collecting means 320 may also becoupled to a source 345 of parameter history and/or other such relatedinformation, such as a database or memory that may or may not be part ofthe analyzer 300 or controller 310. One or more of the analyzer'sconnections allows the analyzer 300 to collect operational data. Datamay be collected once (for example, during a single transceivertraining) or over time. In some cases, the monitoring means 320 willcollect data on a periodic basis, though it also can collect dataon-demand or any other non-periodic basis, thus allowing the analyzer300 to update its user and line data, if desired.

Analyzing means 340 is capable of analyzing data provided to it todetermine whether instructions need to be sent to one or more modems toassist the modems in mitigating noise effects. The analyzing means 340of analyzer 300 is coupled to an instruction-signal generating means 350in the controller 310. Signal generator 350 is configured to accept aparameter value generated by the analyzing means 340 for use by a modem,where the parameter value is based on the operational data and iscalculated to assist at least one modem in mitigating noise, improvingstability, eliminating failures or reducing errors. Signal generator 350is configured to send instruction signals to users in the communicationsystem (for example, ADSL transceivers such as ATU-Cs). As indicated bythe dashed line 347, the instruction signal generating means 350 may ormay not be part of the analyzer 300 and/or be implemented in the samehardware, such as a computer system. Instruction signal generating 350constitutes a means for regulating one or more parameter values in themodem pair.

Another embodiment of the invention is shown in FIG. 3B. A DSL optimizer365 operates on and/or in connection with a DSLAM 385 or other DSLsystem component (for example, an RT, ONU/LT, etc.), either or both ofwhich may be on the premises 395 of a telecommunication company (a“telco”). The DSL optimizer 365 includes a data module 380, which cancollect, assemble, manipulate and/or supply operational data for and tothe DSL optimizer 365. Module 380 can be implemented in one or morecomputers such as PCs, workstations, or the like. Data from module 380is supplied to a DSM server module 370 for analysis (for example,determining the availability of profiles, transitions to be implemented,etc. based on collected operational data for given communication lines,control and operational changes to the communication system, reportedmodem capabilities, etc.). Information also may be available from alibrary or database 375 that may be related or unrelated to the telco. Aprofile selector 390 may be used to implement signals affectingoperation of the communication system. Such decisions may be made by theDSM server 370 or by any other suitable manner, as will be appreciatedby those skilled in the art. Operational modes selected by selector 390are implemented in the DSLAM 385 and/or any other appropriate DSL systemcomponent equipment. Such equipment may be coupled to DSL equipment suchas customer premises equipment 399. Device 385 can be used to implementany ordered changes based on allowable profiles, performanceenhancement, etc. considered by the DSL optimizer 365. The system ofFIG. 3B can operate in ways analogous to the system of FIG. 3A, as willbe appreciated by those skilled in the art, though differences areachievable while still implementing embodiments of the invention.

The collecting means 320 or the data module 380 also may be coupled tothe corresponding modules of a second controller or DSL optimizer. Thus,operational data can be collected from other DSL lines, even when theyare not controlled by the same DSL optimizer, DSM center or SMC.Conversely, a controller 310 or DSL optimizer 365 may provideoperational data of its own DSL lines to a public or private database(for example, a public or privately controlled web site or connectionwhere DSL management entities can share data appropriately) forappropriate use by regulators, service providers and/or other DSLoptimizers. As will be appreciated by those skilled in the art, if thecontroller is a wholly independent entity (that is, not owned and/oroperated by the company owning and/or operating lines within the CO),much of the DSL system's configuration and operational information maybe unavailable. Even in cases where a CLEC or ILEC operates and/orfunctions as the controller 310, much of this data may be unknown.

In some embodiments of the invention, the analyzer 300 may beimplemented in a computer such as a PC, workstation or the like (oneexample of which is disclosed in connection with FIG. 8). The collectingmeans 320, analyzing means 340 and/or instructing signal generatingmeans 350 may be software modules, hardware modules or a combination ofboth, as will be appreciated by those skilled in the art. Thesecomponents may all reside in the same computer system, for example, ormay be in distinct apparatus. For management of large numbers of lines,databases may be introduced and used to manage the volume of datagenerated by the lines and the controller.

An embodiment of the invention can be characterized in two parts: noisecharacterization, and noise mitigation. A discussion of noisecharacterization is provided next, followed by a discussion of noisemitigation.

Noise Characterization

With reference to FIG. 4, one embodiment of the invention is described.At module 405, data is collected. Data collection can be performed asdescribed above with reference to FIG. 3A and FIG. 3B. Data collectionmay be performed multiple times. Data collected may includeinstantaneous values (value at time of data collection), or a history ofvalues (values obtained at various times before data collection). Datathat represent counters (e.g. Code Violations (CV), Errored Seconds(ES)) may be represented as vectors, wherein each element in the vectoris a count within a known time interval. Data can include parametersrelated to the Central Office (CO-side, or sometimes referred to asNear-End, NE), or to the Customer Premises (CP-side, or sometimesreferred to as Far-End, FE).

In one embodiment of the invention the parameters to collect mayinclude:

From G.997.1:

Line Inventory

-   -   G.994.1 vendor ID    -   System vendor ID    -   Version number    -   Serial number

Channel Test, Diagnostic and Status Parameters

-   -   Actual Data Rate    -   Actual Interleaving Delay    -   Actual framer settings:        -   NFEC, RS codeword size        -   RFEC, RS parity bytes        -   LSYMB, bits per symbol        -   INTLVDEPTH, interleaver depth        -   INTLVBLOCK, interleaver block size

Line Test, Diagnostic and Status Parameters

-   -   LATN, line attenuation    -   SATN, signal attenuation    -   SNRM, SNR margin    -   ACTPSD, actual PSD level    -   UPBOKLE, electrical length    -   ACTATP, actual aggregate transmitted power    -   HLIN, complex channel response    -   HLOG, magnitude of channel response    -   QLN, quiet line noise    -   SNR    -   BITS    -   GAINS    -   TSS, transmit spectral shaping    -   MREFPSD, reference PSD    -   TRELLIS    -   ACTUALCE, cyclic extension length

Channel Performance Monitoring Parameters

-   -   CV, code violations    -   FEC, forward-error corrections

Line Performance Monitoring Parameters

-   -   FECS, FEC seconds    -   ES, errored seconds    -   SES, severely errored seconds    -   LOSS, loss-of-signal seconds    -   UAS, unavailable seconds    -   Full initializations (or REINIT)    -   Failed initializations

Line Failures

-   -   LOS, loss of signal failure    -   LOF, loss of frame failure    -   LPR, loss of power failure    -   LINIT, line initialization failure

From WT-135 Revision 4:

Object .STBService.{i}.AVStreams.-AVStream.{i}.IP.RTP.Stats

-   -   PacketsReceived    -   BytesReceived    -   PacketsLost    -   FractionLost    -   CorruptedPackets    -   Overruns    -   Underruns    -   ReceiveInterarrivalJitter    -   AverageReceiveInterarrivalJitter

Object .STBService.{i}.AVStreams.-AVStream.{i}.MPEG2TS.Stats

-   -   PacketsReceived    -   PacketDiscontinuityCounter    -   Overruns    -   Underruns        Additional Parameters from the Dynamic Spectrum Management        Technical Report:    -   MSE, mean-square-error per tone    -   Pb, probability of error per tone    -   Xlog, Xlin, crosstalk coupling    -   MARGIN[i], margin per tone

Additional Parameters:

-   -   SOS notifications/events/counters (resulting in abrupt reduction        of data rate)    -   SRA (Seamless Rate Adaptations) notifications/events/counters    -   Failure causes    -   Bit-swap counts    -   Bit distribution statistics (e.g. min-max-median-average per        tone)    -   Noise peak-to-average ratio (or noise peak in time domain)    -   Echo response    -   Loop impedance    -   Impulse noise width (or related statistics)    -   Impulse noise period (or related statistics)    -   Impulse noise event duration (or related statistics)    -   IPTV or MPEG delivery statistics such as outages, missing        packets, error-concealed packets, retransmitted packets,        missing/interpolated MPEG blocks, buffer overflows/underflows,        retransmissions, etc.    -   Impulse noise can be characterized over time as shown in FIG. 5,        where each noise pulse 510 in an event duration 520 has a width        530 and period 540. Statistics of these quantities (e.g.        histograms, min, max, median, x% worst-case) can be computed and        reported.

Module 410 evaluates link stability and link quality. For evaluation ofthe link stability, parameters such as the line failures specifiedabove, full/failed initializations (also known as retrains), andunavailable seconds (UAS), are obtained as described above with respectto FIGS. 3A and 3B and module 405 of FIG. 4. In some embodiments, adistribution of these quantities over time is evaluated. For example, ifthe LOS is counted in 15 minute intervals, for a total measurementperiod of 1 day, there are 96 LOS counts. Evaluating the distribution ofLOS means evaluating in how many intervals the LOS count was equal to 0,in how many intervals the LOS count was equal to 1, and so on.

Link stability levels are determined from such distributions. In oneembodiment, for example, link stability is declared to be good, if allof the following conditions hold:

-   -   LOS=0 for 90% of the intervals,    -   LOS<=1 for 99% of the intervals,    -   LOS<=2 for 100% of the intervals.

Link stability is declared to be better than moderate, if all of thefollowing conditions hold:

-   -   LOS=0 for 80% of the intervals,    -   LOS<=1 for 90% of the intervals,    -   LOS<=2 for 95% of the intervals,    -   LOS<=4 for 100% of the intervals.

Link stability is declared to be poor in all other cases.

Link stability levels may be determined by a combination of conditionssuch as the above for multiple parameters.

Module 420 of FIG. 4 compares noise before and after link failure. Ifthe link stability is determined to be poor, then a further decision ismade as to the type of noise/disturbance that is causing the poor linkstability. A method to determine the type of noise/disturbance is tocompare the noise at the DSL receiver before a link failure and after alink failure. (A link failure includes a so-called “SOS event” or an SRAevent, where the modem in the DSL receiver remains operational, butreduces its data rate.) A significant difference between the measurednoises indicates that the link failure occurred because of a substantialincrease of the noise level. Comparable noise levels before and afterthe link failure indicate that causes other than an increase in thenoise lead to the link failure.

Such comparisons may be made over multiple time periods corresponding tothe multiple link failures, in order to draw more reliable conclusions.For example, the record of LOS (or full initializations) may be used toidentify the time of a link failure. Multiple noise measurements may beobtained at times before and after the link failures. A change in thenoise level may be considered to be the cause of the link failure if asubstantial change in noise levels is observed for a certain percentageof the total number of link failures.

The noise measurement before the link failure is preferably made atleast a few seconds before the link failure occurs. The noisemeasurement after the link failure should be made after the DSL link hasreinitialized (or after the SOS or SRA procedure to reduce data rate hasconcluded) and is in stable condition (e.g. signal to noise ration (SNR)margin is stable, CV count is low, etc.).

There are many techniques for evaluating the noise of a DSL receiver. Inone method, the receiver reports the mean-square-error (MSE) of itsdecoder. Such error may correspond to a slicer's output, a trellisdecoder's output, or a RS decoder output.

Alternately, the noise may be indirectly computed using otherparameters. For example, if SNR, HLOG (channel attenuation), MREFPSD(transmitted PSD) and GAINS (gain scaling) are reported by a VDSL2modem, then the mean-square-error of the receiver can be estimated bythe following expression:

MSE(dBm/Hz)=HLOG(dB)+MPREFPSD(dBm/Hz)+GAINS(dB)−SNR(dB)

Yet another alternative method is to use SNR margin reported values as ameasure of noise. SNR margin may be reported either as an average or pertone, and in either form it can be used to compare noise before andafter a failure.

Further techniques for estimation of the receiver noise can be found inrelated U.S. patent application Ser. No. 10/817,128, entitled DSL SystemEstimation and Parameter Recommendation, filed 2 Apr. 2004, published asU.S. Publication No. 2005/0123027 on 9 June 2005.

The determination of a substantial change in noise levels typically isbased on the difference between the noise before and after the failure.The difference is a vector of one or more values corresponding todifferent frequencies. In one embodiment, a substantial change isdeclared if the difference is found to exceed a certain threshold for acertain number of frequency points. Weighting factors may be applied todifference values of certain frequencies.

The determination of a substantial noise change can be used to diagnosethe known issue of a “third wire”. In certain countries/regions, theinside wiring for telephony services includes three wires, two for thetransmission of the telephony signal, and one for the ringing signal.Such a practice is nowadays obsolete, however, there continue to existhome installations where a third wire is present. Unfortunately, thisthird wire seriously impairs DSL transmission, because it degrades thebalance of the DSL signal transmission. As a result, external noisesources cause particularly strong interference on DSL. Morespecifically, time-varying noise sources then cause substantial noisechanges, which can lead to link failures. Such noise changes can bedetected using the embodiments described herein, and consequently, thepresence of a third wire can be indicated as a possible root cause.

The determination of a substantial noise change can also be used todiagnose the more general condition of “problem with in-house wiring”.It is occasionally the case that in-house wiring is poorly installed ormaintained, which may degrade the balance of the DSL signaltransmission, and make DSL transmission suffer from external noisesources. Again, detecting noise changes as described herein can aid withdiagnosing in-house wiring problems.

Turning to module 430 of FIG. 4, one embodiment of the invention checksif the link failure is correlated with a power loss. If it is found thatthe noise before and after the link failure is not significantlydifferent, then it is determined that the link failure may be the resultof a power loss, or the result of a severe impulse noise event (forexample, a voltage surge on the line). In order to differentiate betweenthese cases, some additional checks can be performed:

-   -   Check if link failure is correlated with a loss-of-power (LPR)        failure being reported. If an LPR is associated with a failure        event, then the link failure happened because of a power        disruption.    -   Check if a CPE modem (e.g. a USB CPE modem powered by a computer        such as a Personal Computer (PC)) is used on the DSL link. If        such a modem is used, then power-cycling or switching off the PC        at the customer premises results in a line disconnection.    -   Check if neighboring links experience failures at the same or        similar times. In such cases, it may be deducted that multiple        links are suffering from severe impulse noise events.    -   Check for DSL receiver saturation, increase of received signal        power, activation of circuit protection logic, overflow bits or        similar indications. If such indications exist, then it is        likely that a severed impulse noise event has occurred.

In all other cases, the link failure can be attributed to severe impulsenoise events. Thus, the cause of the poor link stability can beidentified either as power loss events, or as severe impulse events.

With reference to module 440, if the link failure is found to becorrelated with a power loss, then information characterizing the linkfailure can be recorded, for example the time/day of link failure can berecorded to provide statistical information about the times, days whensuch events are most likely to happen.

At module 450, if the link failure is found to originate from a severeimpulse event, then information characterizing the link failure can berecorded, for example the time/day of link failure can be recorded toprovide statistical information about the times, days when such eventsare most likely to happen.

Returning to module 420, if it is found that the noise before and afterthe link failure is substantially different, then it is deduced that anabrupt change of the strength of the received noise is the cause of thelink failure. Information characterizing the link failure may berecorded, for example, the time/day of link failure may be recorded toprovide statistical information about the times, days when such eventsare most likely to happen.

The difference in the noise before and after the link failure can bestored and provides valuable information for reconfiguring the link tomitigate the effects of such noise changes. The difference effectivelyreveals the power over different frequencies (power spectral density,PSD) of the noise source that causes the noise change. If such adifference is computed for multiple link failure events, an average canbe computed to provide better reliability. As an alternative tomeasuring the noise difference, quantities such as the differences inthe bit distributions can be used.

Returning to module 410, for evaluation of the link quality, channelperformance monitoring parameters and/or line performance monitoringparameters are obtained as described above with reference to FIGS. 3Aand 3B. In some embodiments of the invention, a distribution of thesequantities over time is evaluated. Higher-layer parameters may also beobtained for applications such as IPTV or other video stream delivery. Alist of such parameters is provided in the DSL Forum document WT-135Revision 4, which is well known to those skilled in the art.

Link quality levels are determined from evaluation of suchdistributions. In one embodiment, for example, link quality is declaredto be acceptable, if all of the following conditions hold:

-   -   CV<=1 for 95% of the intervals,    -   CV<=10 for 99% of the intervals,    -   CV<=100 for 100% of the intervals,    -   SES<=1 for 95% of the intervals,    -   SES<=15 for 99% of the intervals,    -   SES<=60 for 100% of the intervals.

The link quality is declared to be unacceptable in all other cases.

Other quantities can be derived from the above parameters. These couldinclude summations (e.g. UAS+SES), or more elaborate expressions (e.g.CV/(360e3−(SES+UAS)*400)). Expressions such as these may be constructedfor parameters associated with either the CO-side or the CP-side or withboth the CO-side and the CP-side. Such expressions may be dependent onthe vendor and/or system ID.

If at 410 the link quality is determined to be poor, then furtheranalysis of the errors can be performed at module 470 to determine ifthe impulse noise events causing the poor quality are intermittent orpersistent. The fundamental difference for such characterization is theimpulse noise event duration (see FIG. 5).

A method to perform such characterization is to observe the codeviolation (CV) counters. Large values for the CV counters over asignificant percentage of time indicate that the impulse noise eventduration is long, and that the impulse noise can be classified aspersistent or repetitive. An example criterion for declaring repetitiveimpulse noise is to satisfy at least one of the conditions below:

-   -   CV>=100 for 10% of the intervals, or    -   CV>=1000 for 5% of the intervals.

Alternative parameters can be used, or criteria can be constructed usingcombinations of rules with multiple parameters such as:

-   -   FEC, number of corrected codewords    -   FECS, FEC seconds    -   ES, errored seconds    -   SES, severely errored seconds    -   LOSS, loss-of-signal seconds    -   UAS, unavailable seconds

CV and FEC are advantageous, because they have a finer granularitycompared to counts of seconds. Any conditions derived from parameterssuch as the above may also incorporate performance parameters such asdata rate and margin.

In some embodiments, more detailed information about the impulse noisemay be provided by the DSL systems. For example, information mayinclude:

-   -   Averages, statistics, or distributions of impulse noise width,    -   Averages, statistics, or distributions of impulse noise period,    -   Averages, statistics, or distributions of impulse noise event        duration.

The impulse noise may then be characterized as repetitive if all of theconditions below are satisfied:

-   -   Impulse noise event duration>x seconds (e.g. 10 seconds)    -   Impulse noise period<y milliseconds (e.g. 1000 milliseconds)    -   Impulse noise width>z DMT symbols (e.g. 0.5 DMT symbols)

If these conditions are not met, then the noise is classified asintermittent impulse noise.

In other embodiments, the impulse noise may be characterized byexamining information about network layers higher than the DSL physicallayer. For example, information may include:

-   -   Averages, statistics, or distributions of lost or corrupted        packets/MPEG frames.    -   Averages, statistics, or distributions of packet inter-arrival        jitter.    -   Averages, statistics, or distributions of MPEG buffer overruns        and under-runs.

For example, the impulse noise may then be characterized as repetitiveif all of the conditions below are satisfied:

-   -   Lost packets>x1 for 10% of the measurement intervals, or    -   Lost packets>x2 for 5% of the measurement intervals.

Any of the above conditions may be dependent on the vendor and/or systemID.

As a next step 480, after declaring the cause of the poor link qualityas repetitive impulse noise, further analysis may be performed.

Information characterizing the failure may be recorded, for example thetime/day of poor quality can be recorded to provide statisticalinformation about the times, days when such events are most likely tohappen. This can be achieved for example by recording the intervals whenCV or some other channel/line performance monitoring parameter exceeds acertain threshold.

The impulse noise event duration can be also estimated by using channelor line performance monitoring parameters and recording the length oftime over which these parameters exceed a certain threshold.

The impulse noise width and period may also be estimated, if theintervals for measuring performance monitoring parameters are made shortenough to be in the order of microseconds. Even if such short intervalsare not possible, the repetitive impulse noise can still beapproximately characterized based on the performance monitoringparameters. For example, the repetitive impulse noise may becharacterized as level 1, if

-   -   CV>=100 for 10% of the intervals, or    -   CV>=1000 for 5% of the intervals;        or may be characterized as level 2, if    -   CV>=100 for 20% of the intervals, or    -   CV>=1000 for 10% of the intervals.

Repetitive impulse noise may affect certain frequencies more thanothers. A method to identify the affected frequencies is next explained.

It has been observed that repetitive impulse noise can have an effect onthe average noise experienced by a DSL receiver. If noise measurementsare performed before an impulse noise event starts, and while an impulsenoise event is in progress, then these noise measurements may besubstantially different. (The same effect can be noticed by performingSNR margin measurements.) By recording the frequencies over which thenoise is substantially different, one can identify the frequencies withthe highest susceptibility to repetitive impulse noise. Methods takingadvantage of such knowledge are discussed in more detail below.

If, at 470, intermittent impulse noise is declared the cause of the poorlink quality, further analysis may also be performed. Informationcharacterizing the link failure can be recorded, for example thetime/day of poor quality can be recorded to provide statisticalinformation about the times, or days when such events are most likely tohappen. This can be achieved for example by recording the intervals whenCV or some other channel/line performance monitoring parameter exceeds acertain threshold.

The impulse noise event duration, impulse noise width and impulse noiseperiod may also be estimated using method similar to those forrepetitive impulse noise. Note that the noise characterization does notneed to be unique in its declaration of the cause. For example, it maybe determined that both link stability and link quality is poor, withabrupt noise changes contributing to link instability, and intermittentimpulse noise contributing to the poor link quality. In such cases, anembodiment of the invention may implement the steps following steps 420and 470, either sequentially or in parallel.

Noise Mitigation

With reference to FIG. 6, the noise mitigation actions depend on theresults of noise characterization 605 as outlined in the abovediscussion. In one embodiment of the invention, noise mitigation isaccomplished by DSL link reconfiguration as shown in FIGS. 3A and 3B.Multiple rounds of data collection and link reconfiguration may beperformed to achieve suitable noise mitigation.

A list of parameters that may be controlled includes:

From G.997.1:

Line Configuration Parameters

-   -   MAXNOMPSD, maximum nominal PSD    -   MAXNOMATP, maximum nominal aggregate transmitter power    -   MAXRXPWR, maximum received power    -   CARMASK, carrier mask    -   PSDMASK, PSD mask    -   RFIBANDS, RFI bands    -   DPBOSHAPED, downstream power back-off    -   UPBOSHAPED, upstream power back-off    -   TARSNRM, target SNR margin    -   MAXSNRM, maximum SNR margin    -   MINSNRM, minimum SNR margin    -   MSGMIN, minimum rate for message overhead channel

Channel Configuration Parameters

-   -   Minimum data rate    -   Maximum data rate    -   Maximum interleaving delay    -   Minimum impulse noise protection    -   FEC redundancy ratio        Additional from DSM TR:    -   Margin cap mode    -   Band preference        Additional parameters:    -   TARSNRM[n], target SNR margin per tone    -   BCAP[n], bit cap per tone    -   Retrain thresholds    -   Retransmission parameters for DSL layer

If at 605 stationary noise 610 is determined to be the cause of linkinstability, then at 615 one or more particular reconfigurations of theDSL link according to embodiments of the invention may mitigate theproblem. Stationary noise analysis produces an estimate of the change ofnoise before and after a link failure. Estimates of the power spectraldensity of the new noise may provide extra protection to the affectedfrequencies, and to prevent a link failure when such a noise change asrepeated.

A summary of possible counter-measures that can be employed at 615 toincrease protection for affected frequencies follows:

-   -   1. Additional SNR margin may be provisioned for the DSL link, so        that the noise change does not cause a drop of the SNR margin to        negative values. This can be achieved by either reducing the        maximum data rate of the DSL link, or by requiring a larger        TARSNRM (target SNR margin).    -   2. The frequencies that are most affected by the abrupt noise        change may be disabled. This can be achieved by either using        CARMASK (carrier mask), or PSDMASK (PSD mask) to make sure that        those frequencies are not loaded with any bits. Thus, an abrupt        noise change will have a smaller effect on the DSL link.    -   3. The frequencies that are most affected by the abrupt noise        change may be provided with additional margin. This can be        achieved by appropriately programming the configuration        parameters to assure that those frequencies have more margin        compared to other frequencies, e.g. by using a tone-dependent        TARSNRM[n] parameter as described in the standards contribution        T1E1.4/1992-203 by John M. Cioffi of Amati Communications.        Another very effective approach is to use a tone-dependent        bit-cap (BCAP[n]) to prevent the affected frequencies from being        loaded with too many bits, and thus assuring the extra        protection.    -   4. A novel approach towards providing additional protection is        to use a tone-dependent MAXSNRM[n] parameter, or maximum SNR        margin. This approach allows systems characterized by excess        margin to perform power cutback such that certain tones are        allowed more protection against noise than others. For example,        tones where abrupt noise changes are observed to have an impact        may be allowed a MAXSNRM of 20 dB, while tones with no such        impact may be allowed a MAXSNRM of only 6 dB. This practice        combines the benefit of having a MAXSNRM setting, forcing power        reduction in cases of connections with excess margin, with the        benefit of giving preferential treatment to certain frequencies        so that they can more effectively cope with abrupt noise change.    -   5. Another novel approach towards offering better protection for        those tones experiencing abrupt noise changes is to mark such        tones so that the bit-swapping behavior is more conservative for        such tones. In one embodiment, marked tones are prevented from        increasing their number of loaded bits using bit-swapping. Such        a measure assures that time-varying noise can only make those        tones decrease their number of loaded bits. Thus, some temporary        improvement in the noise conditions after initialization does        not result in a higher number of bits for those tones where        noise may later be abruptly increased and possibly cause an        undesired line failure.    -   6. In another embodiment, marked tones may be prevented from        increasing their number of loaded bits using bit-swapping, only        after they reach a certain number of loaded bits. This approach        can be viewed as a variation of BCAP[n], with the significant        difference being that the “bit cap” constraint applies to the        operation during SHOWTIME, and does not necessarily apply for        the loading algorithm during initialization.

If at 605 severe noise impulses 620 are determined to be the cause oflink instability, then one ore more particular steps 625, according toembodiments of the invention, may mitigate the problem. Severe noiseimpulses causing such link instability are typically characterized byimpulse noise signals with voltages strong enough to cause the DSL modemsurge protection circuitry to be activated. During that time, thereceived signal is seriously corrupted, and logic may be activated toinitiate a retrain. The triggering of a retrain can be based on criteriasuch as loss-of-margin (LOM) indications, an excessive number of codeviolations within a short period of time, and others.

A possible mitigation strategy is to adjust the trigger conditions forretrain, so that when a severe noise impulse is observed, a retrain isnot immediately initiated. If there is knowledge of severe noiseimpulses affecting a link, then making the retrain conditions morestringent will make retrain events more rare. A DSL system may then beable to recover from such severe noise impulses while remaining inShowtime, and using Showtime adaptation techniques. Examples ofadjusting such trigger conditions follow:

-   -   Adjust MINSNRM to smaller values, so that loss-of-margin does        not trigger a retrain.    -   Adjust the threshold for code violations per unit of time, which        triggers a retrain.    -   Adjust the threshold for decoder errors per unit of time, which        triggers a retrain.

These trigger conditions may also relate to an SOS event. At times whena receiver detects a severe degradation of the signal, the correspondingDSL modems may use the SOS protocol to negotiate a substantial reductionof the data rate. This approach can be considerably faster compared tothe process of a complete retrain, which leads to no or minimalinterruption to the DSL service. The conditions for triggering such anSOS event can be similar to those described above for retrains, such asloss-of-margin indications, excessive counts of code violations within aperiod of time, excessive counts of decoder errors within a period oftime, etc.

These methods can be further enhanced if logic is included in the analogfront end of the modem to detect the occurrence of a severe noiseimpulse. The output of such logic would be a signal to the modem'scontroller circuitry that would indicate that a retrain should not beperformed for the duration of the severe noise impulse and for a fewseconds after the noise impulse has disappeared.

If at 605 power loss events 630 are determined to be the cause of lineinstability, then, at 635, according to embodiments of the invention, noDSL reconfiguration step is taken to mitigate this effect. Other actionssuch as notifying operations, or notifying the customer of this issuemay however be taken.

If at 605 intermittent impulse noise events 640 are determined to be thecause of poor line quality, then at step 645, one or more particularreconfigurations of the DSL link according to embodiments of theinvention may mitigate the problem.

Knowing or having an estimate of the impulse noise width and period canaid with properly configuring the DSL link to provide adequate impulsenoise protection. The estimate of the impulse noise width is useful forchoosing the parameter of minimum impulse noise protection.Specifically, the minimum impulse noise protection must be chosen to beat least as long as the estimated impulse noise width. At the same time,the codeword span must be shorter than the estimated impulse noiseperiod. The codeword span can be approximately by the interleaver delayquantity. A set of conditions for configuring the DSL link follow:

-   -   1. Minimum impulse noise protection>estimated impulse noise        width;    -   2. Maximum delay<estimated impulse noise period.

If the second condition cannot be met, then the minimum impulse noiseprotection must be further increased, so that the RS code can cope withmultiple impulse noise occurrences within the codeword span.

Similar criteria can be used for configuring the DSL systems'retransmission module to provide adequate impulse noise protection. Inpotential DSL systems implementing retransmission techniques at the PHYlayer, there exist configuration parameters for retransmission, such asminimum impulse noise protection, maximum delay, minimum inter-arrivaltime, and minimum RS overhead. Such configuration parameters may beprogrammed as follows:

-   -   1. Minimum impulse noise protection>estimated impulse noise        width    -   2. Minimum inter-arrival time<estimated impulse noise period    -   3. Maximum delay<delay budget    -   4. Minimum RS overhead>x*(estimated number of bytes in error as        a percentage of all bytes in a RS codeword), where x=2 without        erasure decoding, and 1=<x<2 with erasure decoding. (Note that        the Minimum RS overhead may be controlled either directly, or        indirectly, e.g. through controlling parameters for FEC.)

The above rules for choosing the configuration parameters are furtherexplained: Certain DSL modems may employ simultaneously re-transmissionmodules and modules implementing Forward-Error-Correction (FEC, e.g. RSencoding/decoding) and interleaving. In such cases, the configurationparameters may include parameters related to both the re-transmissionmodule, and to the FEC and interleaving modules. For such embodiments,there are trade-offs that exist between using re-transmission and FECfor correcting impulse noise. The relative preference towards one versusthe other depends on the impulse noise characteristics.

More specifically, if the estimated impulse noise period is relativelyshort compared to the duration of a DMT symbol, then this indicates thatthe impulse noise is persistent, and that retransmission schemes usedalone may be incapable of providing proper protection. If impulse noiseaffects a large number of consecutive DMT symbols, then attempts toretransmit those symbols will result in further failures, and mayeventually cause retransmission buffers to overflow. On the other hand,if RS coding can correct for the errored bytes in the consecutive DMTsymbols, then the combination of retransmission with RS coding will leadto error-free transmission. In such cases, a selection of theconfiguration parameters as indicated above would be most beneficial.

The configuration parameter for minimum impulse noise refers toprotection offered at the input point of the RS decoder (or of there-transmission module), and not at the tip-to-ring point of the modem.An impulse of a certain length at tip-to-ring may spread and have alarger width after undergoing receiver processing. It is also noted thatpractical designs have limitations on the possible choices for minimumimpulse noise protection, maximum delay, and data rate. Such limitationscan be taken into account when configuring the DSL link.

An additional technique for reducing the impact of intermittent impulsenoise is to adjust the bit loading on those tones which are known orsuspected to be strongly affected by such noise. Example methods arehere outlined:

-   -   1. Use BCAP[n] to force tones to load with a smaller number of        bits. Such programming of BCAP[n] reduces the number of tones        with a large number of bits and possibly increases the number of        tones with a smaller number of bits. This has the effect of        increasing impulse noise immunity, especially when impulse noise        is the result of receiver clipping. Assuming that impulse noise        has approximately the same strength on those tones which are        affected (as is the case with receiver clipping), then tones        loaded with a small number of bits have improved immunity,        compared to tones loaded with a large number of bits. Thus, by        not allowing tones to be loaded with a large number of bits, the        overall impulse noise immunity is improved.    -   2. Increase protection over those tones that may be strongly        affected by impulse noise. Example techniques for achieving this        include:        -   a. Disabling those tones by use of CARMASK, PSDMASK or other            equivalent parameters.        -   b. Use of BCAP[n] for those tones to force a small number of            bits.        -   c. Use of PSDMASK or TARSNRM[n] for those tones to force a            small number of bits.

Yet another technique, explained in more detail below, for improving therobustness of the DSL link to impulse noise is to use the knowledgeabout tones most affected by such noise in order to aid the Reed Solomon(RS) decoder of the DSL receiver.

RS encoding adds a certain number of “parity” bytes to a number of“payload” bytes to form an RS codeword. At the RS decoder, the number ofbytes in error that can be corrected per RS codeword is generally equalto one half the number of parity bytes. However, if information isavailable about the location of bytes in error, then the errorcorrection capability is doubled and becomes equal to the number ofparity bytes. In this latter case, it is said that “erasure” decoding isperformed. A challenge in implementing receivers with erasure decodersis the need to have information about the location of the bytes inerror, or the erasures.

However, knowledge of the tones where impulse noise has the strongesteffect is valuable for erasure decoding. Starting from the toneinformation, provided by embodiments of the invention, a reliableerasure forecasting process can be constructed which can identify thelocations of the bytes within a RS codeword that have high probabilityof being corrupted by impulse noise. This is illustrated in FIG. 7.

If at 605 repetitive impulse noise events 650 are determined to be thecause of line instability, then at Step 655, a certain DSLreconfiguration can help with the mitigation of this effect.

The same techniques as those described for intermittent impulse noisecan be applied, but with one important difference: With repetitiveimpulse noise, the averaged receiver noise (or equivalently the measuredmargins, or measured SNR levels) is affected by the impulses. Thiseffect can be advantageously used during noise characterization to moreaccurately identify the frequencies where impulse noise has thestrongest effect.

By knowing these frequencies, techniques for reducing the impact ofimpulse noise by adjusting the bit loading can be made more effective.Example methods are next outlined:

-   -   1. Set BCAP[n]=BITS[n]−2, for those values of n corresponding to        affected frequencies. BITS[n] is the bit distribution previously        obtained.    -   2. Set BCAP[n]=0, (or set CARMASK[n]=1, or set PSDMASK[n]=−100        dBm/Hz) for those values of n corresponding to affected        frequencies.    -   3. Set PSDMASK[n]=−70 dBm/Hz, (or set TARSNRM[n]=40 dB) for        those values of n corresponding to affected frequencies.

FIG. 8 illustrates a typical computer system that can be used by a userand/or controller in accordance with one or more embodiments of theinvention. The computer system 800 includes any number of processors 802(also referred to as central processing units, or CPUs) that are coupledto storage devices including primary storage 806 (typically a randomaccess memory, or RAM), primary storage 804 (typically a read onlymemory, or ROM). As is well known in the art, primary storage 804 actsto transfer data and instructions uni-directionally to the CPU andprimary storage 806 is used typically to transfer data and instructionsin a bi-directional manner. Both of these primary storage devices mayinclude any suitable of the computer-readable media described above. Amass storage device 808 also is coupled bi-directionally to CPU 802 andprovides additional data storage capacity and may include any of thecomputer-readable media described above. The mass storage device 808 maybe used to store programs, data and the like and is typically asecondary storage medium such as a hard disk that is slower than primarystorage. It will be appreciated that the information retained within themass storage device 808, may, in appropriate cases, be incorporated instandard fashion as part of primary storage 806 as virtual memory. Aspecific mass storage device such as a CD-ROM 814 may also pass datauni-directionally to the CPU.

CPU 802 also is coupled to an interface 810 that includes one or moreinput/output devices such as such as video monitors, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, or other well-known input devices such as, ofcourse, other computers. Finally, CPU 802 optionally may be coupled to acomputer or telecommunications network using a network connection asshown generally at 812. With such a network connection, it iscontemplated that the CPU might receive information from the network, ormight output information to the network in the course of performing theabove-described method steps. The above-described devices and materialswill be familiar to those of skill in the computer hardware and softwarearts. The hardware elements described above may define multiple softwaremodules for performing the operations of this invention. For example,instructions for running a codeword composition controller may be storedon mass storage device 808 or 814 and executed on CPU 802 in conjunctionwith primary memory 806. In a preferred embodiment, the controller isdivided into software submodules.

The many features and advantages of the invention are apparent from thewritten description, and thus, the appended claims are intended to coverall such features and advantages of the invention. Further, sincenumerous modifications and changes will readily occur to those skilledin the art, the invention is not limited to the exact construction andoperation as illustrated and described. Therefore, the describedembodiments should be taken as illustrative and not restrictive, and theinvention should not be limited to the details given herein but shouldbe defined by the following claims and their full scope of equivalents,whether foreseeable or unforeseeable now or in the future.

What is claimed is:
 1. A computer-implemented method of characterizing noise associated with a digital subscriber line (DSL) link, comprising: receiving at a controller data indicative of a level of stability of the DSL link; determining at the controller whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold; if the level of stability of the DSL link is below the minimum threshold, the controller: comparing a noise level associated with the DSL link before a time of failure with a noise level associated with the DSL link after the time of failure; if a difference between the noise level before and after the time of failure exceeds a threshold, then characterizing the noise as a stationary noise associated with the DSL link; if the difference between the noise level before and after the time of failure is below the threshold, investigating whether the failure is associated with a loss of power to the DSL link or a severe impulse noise event and characterizing the noise accordingly; and recording the characterization of the noise associated with the DSL link.
 2. The method of claim 1, further comprising the controller estimating a time of a failure of the DSL link based on the data, and wherein comparing the noise level associated with the DSL link before a time of failure with the noise level associated with the DSL link after the time of failure comprises comparing a noise level associated with the DSL link before the estimated time of failure with a noise level associated with the DSL link after the estimated time of failure.
 3. The method of claim 1, wherein comparing noise associated with the DSL link comprises comparing at a DSL receiver coupled to the associated DSL link the noise level before the time of failure with the noise level after the time of failure.
 4. The method of claim 1, further comprising the controller evaluating a distribution of the received data over time, and wherein determining at the controller whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold comprises determining at the controller whether the distribution of data indicates a level of stability of the DSL link that is above or below a minimum threshold.
 5. The method of claim 1, wherein comparing the noise level associated with the DSL link before a time of failure with the noise level associated with the DSL link after the time of failure comprises comparing the noise level associated with the DSL link before a time of failure with the noise level associated with the DSL link after the DSL line is reinitialized and in a stable condition.
 6. The method of claim 1, wherein the noise level is measured according to at least one of mean-square-error of a decoder of a DSL receiver coupled to the DSL link, and signal to noise ratio (SNR) margin.
 7. The method of claim 1, wherein the difference between the noise level before and after the time of failure is calculated as a vector of values corresponding to a plurality of different frequencies, and whether the noise level exceeds or fails below the threshold comprises whether the noise level exceeds or falls below the threshold for a number of the plurality of different frequencies.
 8. An article of manufacture comprising a non-transitory computer readable medium containing instructions that when executed by a computing system, cause the computing system to perform the following steps: receiving data indicative of a level of stability of a Digital Subscriber Line (DSL) link; determining whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold; if the level of stability of the DSL link is below the minimum threshold: comparing a noise level associated with the DSL link before a time of failure with a noise level associated with the DSL link after the time of failure; if a difference between the noise level before and after the time of failure exceeds a threshold, then characterizing the difference in noise as a stationary noise associated with the DSL link; if the difference between the noise level before and after the time of failure is below the threshold, investigating whether the failure is associated with a loss of power to the DSL link or a severe impulse noise event and characterizing the difference in noise accordingly; and recording the characterization of the noise associated with the DSL link.
 9. The article of manufacture of claim 8, further comprising instructions that when executed by the computing system, cause the computing system to perform the step of estimating a time of a failure of the DSL link based on the data, and wherein the instruction for comparing the noise level associated with the DSL link before a time of failure with the noise level associated with the DSL link after the time of failure comprises an instruction for comparing the noise level associated with the DSL link before the estimated time of failure with the noise level associated with the DSL link after the estimated time of failure.
 10. The article of manufacture of claim 8, further comprising instructions that when executed by the computing system, cause the computing system to perform the step of evaluating a distribution of the received data over time, and wherein the determining whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold comprises determining whether the distribution of data indicates a level of stability of the DSL link that is above or below a minimum threshold.
 11. The article of manufacture of claim 8, further comprising instructions that when executed by the computing system, cause the computing system to perform the step of reconfiguring the DSL link responsive to the recorded characterization of the noise associated with the DSL link.
 12. The article of manufacture of claim 8, further comprising instructions that when executed by the computing system, cause the computing system to perform the following steps: determining whether the distribution of performance monitoring data indicates a level of quality of the DSL link that is above or below a minimum threshold; if the level of quality of the DSL link is below the minimum threshold: characterizing whether any impulse noise events associated with the DSL link are intermittent or persistent; recording the characterization of the impulse noise events associated with the DSL link.
 13. The article of manufacture of claim 12, wherein the instructions for recording the characterization of the impulse noise events associated with the DSL link further comprises instructions for recording at least one of a date, time, duration, and affected frequency, associated with each of the impulse noise events.
 14. The article of manufacture of claim 12, further comprising instructions that when executed by the computing system, cause the computing system to perform the step of reconfiguring the DSL link responsive to the recorded characterization of impulse noise events.
 15. A apparatus to characterize noise associated with a digital subscriber line (DSL) link, comprising: collecting means for receiving data indicative of a level of stability of a DSL link; analyzing means for: determining whether the data indicates a level of stability of the DSL link that is above or below a minimum threshold; if the level of stability of the DSL link is below the minimum threshold: comparing a noise level associated with the DSL link before a time of failure with a noise level associated with the DSL link after the time of failure; if a difference between the noise level before and after the time of failure exceeds a threshold, then characterizing the noise as a stationary noise associated with the DSL link; if the difference between the noise level before and after the time of failure is below the threshold, investigating whether the failure is associated with a loss of power to the DSL link or a severe impulse noise event and characterizing the noise accordingly; and recording the characterization of the noise associated with the DSL link.
 16. The apparatus of claim 15, wherein the analyzing means comprises further means for estimating a time of a failure of the DSL link based on the data, and wherein the analyzing means for comparing the noise level associated with the DSL link before a time of failure with the noise level associated with the DSL link after the time of failure comprises analyzing means for comparing a noise level associated with the DSL link before the estimated time of failure with a noise level associated with the DSL link after the estimated time of failure.
 17. The apparatus of claim 15, wherein the noise is measured according to at least one of mean-square-error of a decoder of a DSL receiver coupled to the DSL link, and signal to noise ratio (SNR) margin.
 18. The apparatus of claim 15, further comprising means for reconfiguring the DSL link responsive to the recorded characterization of the noise associated with the DSL link.
 19. The apparatus of claim 15, wherein: the collecting means further receiving a distribution of performance monitoring data indicative of a level of quality of the DSL link; the analyzing means further determining: whether the distribution of performance monitoring data indicates a level of quality of the DSL link that is above or below a minimum threshold; if the level of quality of the DSL link is below the minimum threshold: characterizing whether any impulse noise events associated with the DSL link are intermittent or persistent; recording the characterization of the impulse noise events associated with the DSL link.
 20. The apparatus of claim 19, wherein the performance monitoring data comprises at least one of channel-, line-, or higher-layer performance monitoring data. 